前言

今天主要介紹 IoT 嵌入式系統從開機到執行程式的完整流程與各階段的互動方式。

0x00 Bootup

從按下電源鍵到載入 Bootloader、Firmware、Memory 的流程，大致可以 BIOS 和 UEFI 規格來說明：由左至右，第一階段的 Bootloader 原先以「初始化剛好足夠的硬體」出發，但隨著時間推移，已能支援執行時設定、GUI、Secure Boot、自動更新等功能。[1]

0x01 Firmware 哪來那麼多種

作為硬體與軟體之間的介接，Firmware 主要分成以下幾類型：

                    Embedded Firmware
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
     Bare Metal           RTOS          General-purpose OS
        │                  │                  │
     無 OS              FreeRTOS          Embedded Linux
                         Zephyr           Android
                         ThreadX          ...
                         VxWorks
                         QNX
                         RTEMS
                         ...

• Bare Metal：直接一個 binary 檔案，常見於小型裝置
• RTOS：通常跑在 MCU 或資源較有限的處理器，常見於無人機、感測器等
  • 典型流程：Task → Callback → Parser → Memory operation → Peripheral
  • 負責即時處理的core + 一組 tasks + drivers + application
• Embedded Linux：較複雜的 IoT 設備，常見於路由器、NAS
  • 許多開源路由器韌體（例如 OpenWrt）也是建立在 Embedded Linux 之上
  • 完整 OS + userspace 生態系
• 當裝置有多個 CPU/MCU 時，常見 RTOS + Embedded Linux 混用（一個負責檔案系統，一個負責即時介面處理）

0x02 Memory 與儲存層

IoT 裝置的記憶體大致可分成以下幾類：

1. Volatile Memory（揮發性）

   • SRAM / DRAM：執行時使用的記憶體，斷電即消失
   • 用來跑 Bootloader、Kernel、Application、Stack/Heap

2. Non-Volatile Memory（非揮發性）

   • NOR Flash：可直接 XIP（Execute-In-Place），常用來放 Bootloader、小容量韌體
   • NAND Flash：容量較大、成本較低，但需要壞塊管理，常用來放 RootFS、Data
   • SPI NOR / SPI NAND：透過 SPI 介面連接，許多 SOHO Router 使用
   • eMMC / UFS：常見於較高階 IPC、NAS、手機
   • EEPROM / OTP：容量很小，用來存 MAC、校準資料、序號等

3. 特殊用途

   • NVRAM（有些是 Flash 模擬，有些是真正的 NVRAM）
   • ART / Caldata（WiFi 校準資料，通常獨立成一個 MTD partition）

這些硬體儲存會被 Linux 透過 MTD（Memory Technology Device） 或 Block Device 抽象成 partition，再掛載成 SquashFS、JFFS2、UBIFS 等檔案系統。

0x03 IoT Firmware 裡面有什麼？

以常見的 Embedded Linux Firmware 為例，內部大致包含：

Firmware
├── Bootloader          ← 硬體初始化
├── Kernel / RTOS       ← 作業系統核心
├── Root Filesystem (RootFS)
│   ├── BusyBox
│   ├── /lib
│   ├── /www
│   ├── /usr
│   ├── Vendor Applications
│   ├── Configuration Files
│   └── Startup Scripts
├── Data Partition      ← 可讀寫資料（常為 JFFS2 / UBIFS）
├── NVRAM / MTD         ← 非揮發性設定與校準資料
└── Firmware Update Mechanism

上圖引用 Zephyr RTOS 的架構 [2]，用來對照 RTOS 的垂直分層。後文提到的 Driver、Kernel、Application 等概念在 RTOS 中的位置，可作為很好的參考。

Bootloader

用途：韌體啟動的第一段程式，負責硬體初始化與載入 Kernel，常見為 U-Boot 或廠商自製。
利用：在 Bootloader 階段可以提取 Kernel 與 RootFS，也是解密 firmware image 的常見切入點。

常見 Bootloader

1. U-Boot (Universal Boot Loader)

• 最常見的開源 Bootloader
• 支援 ARM、MIPS、PowerPC、x86
• 提供網路功能（TFTP、NFS boot）
• 可透過 UART 進入互動模式

研究價值：

• 可以從 UART 中斷開機流程
• 查看記憶體佈局
• dump Flash
• 修改啟動參數（例如進入單使用者模式）

攻擊向量：

• Bootloader 漏洞導致的持久化後門
• Un-auth 的 U-Boot console
• Firmware 驗證機制繞過

2. CFE (Common Firmware Environment)

• Broadcom 晶片專用
• 大量出現在 ASUS、Netgear、D-Link 產品
• 功能類似 U-Boot

Bootloader 研究技巧

Bootloader Interaction
│
├── Console
│   └── UART / USB Serial
├── Network
│   └── TFTP / DHCP / HTTP / Recovery
├── Physical
│   └── Button / GPIO / USB / Storage
├── Debug
│   └── JTAG / SWD / DAP
├── Firmware Access
│   └── RAM / Flash / Boot Arguments
└── Security Boundary
    ├── Secure Boot
    ├── Signature Verification
    ├── Recovery
    ├── Downgrade
    └── Fault Injection

以功能區分有以上這些類別，通常會使用對應工具進行探測，取得 interactive shell 與開機流程 Log。具體應用範例會在後續章節說明。

Kernel / RTOS

用途：作業系統核心，負責記憶體管理、行程排程、驅動載入等。可能是 Linux Kernel、RTOS（FreeRTOS、VxWorks 等）或完全客製。
互動：

• Linux一般透過 ioctl 等方式與底層驅動互動，以 wifi 裝置為例大概是這樣：

int fd = open("/dev/wl0", O_RDWR);          // 打開 WiFi 裝置
ioctl(fd, WL_IOCTL_SET_SSID, &ssid_struct); // 設定 SSID
ioctl(fd, WL_IOCTL_GET_SSID, &ssid_struct); // 讀取 SSID
close(fd);

• RTOS 一般沒有 ioctl，會直接 call API 或使用 Message Queue 跟驅動互動

RootFS - 根檔案系統

用途：包含用戶空間的所有程式與設定檔（BusyBox、網路服務、設定檔、應用程式與 libraries）
互動：定位相關程式與設定檔位置，由於通常會使用不同的壓縮方式進行壓縮，解壓縮也不能單靠 binwalk，可以使用對應工具重建檔案架構和 linking

人類的話可以搭配 fzf 快速定位檔案，Agent 的部分之前試過 codegraph 種完 AST 之後再來逆向

常見檔案系統類型

1. SquashFS

• 特性：Read-only、高壓縮比
• 用途：儲存 base system
• 壓縮演算法：LZMA、LZO、XZ、ZSTD
• Magic Bytes：hsqs
• 搭配工具：unsquashfs、dd、sasquatch

2. JFFS2

• 特性：Read-write、wear-leveling
• 用途：設定檔、log、用戶資料
• Magic：0x1985
• 搭配工具：jefferson

3. UBIFS

• 針對 NAND Flash 優化
• 現代裝置常見的 RW partition
• 依賴 UBI layer
• 特徵：.ubi格式
• 搭配工具：ubireader

4. CramFS

• Magic：0x28CD3D45
• 特性：較舊型的設備常用
• 搭配工具：cramfsprog、firmware-mod-kit(有時候會有奇效)

其他解壓縮工具

• 通用型可以試試 binwalk、7zip、squashfs-tools 這種
• 專門針對 embed system 的 可以看看 vmlinux2elf、yaffs2utils

File System 目錄結構

以 RootFS 為例：

/
├── bin/           # busybox symlinks
├── sbin/
├── etc/           # init process, configs
│   ├── init.d/
│   ├── config/
│   ├── passwd
│   └── shadow
├── lib/
│   └── modules/
├── usr/
├── www/           #  Web interface
│   ├── cgi-bin/
│   ├── luci/
│   └── htdocs/
├── dev/
├── proc/
├── sys/
└── tmp/

可以優先看看

1. 啟動腳本 /etc/init.d/：哪些服務會自動啟動？有無不安全參數？是否有隱藏 debug service？
2. Web Interface /www/：常見 Web Server 像是 lighttpd、CGI、uhttpd 等
3. 被挖完了但還是可以看看的 /etc/passwd & /etc/shadow：偶爾有奇怪的 MD5 hash 可用暴力破解

Data Partition

RootFS、SquashFS 通常是唯讀，可寫入的資料會放在 Data Partition，常見掛載點為 /jffs、/overlay、/data，可用 mount 來查看

NVRAM / MTD

除了檔案系統，韌體還有一類的儲存，用來放設定值和校準資料

NVRAM

用途：儲存 WiFi 密碼、Admin 憑證、WAN/LAN 設定、Bootloader 參數等。

MTD (Memory Technology Device)

e.g.,

$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 002b0000 00010000 "kernel"
mtd3: 00500000 00010000 "rootfs"
mtd4: 00010000 00010000 "nvram"
mtd5: 00010000 00010000 "art"

這邊也可以用dd dump出來看

0x04 各層級的常見利用手法

了解韌體各層面的介紹後，我們可以對應回常見的攻擊手法：

延伸閱讀：後續在討論 AI 輔助韌體研究時，會提到如何讓模型理解這類多層相依關係，以及一些專案中的實作結構。

Take Away

你看了什麼：

• Bootloader 101
• Firmware 的主要結構（Bootloader → Kernel → RootFS → Data → NVRAM）
• Memory 類型和 Bootloader 的關係
• 不同檔案系統的解壓縮方法

你可以給 AI 什麼 insight：

• 在它卡在 recon 時，快速辨認哪些 layer 已經搜尋過 / 還沒測到
• 找到感興趣的方向後，丟給它相關關鍵詞與 skills 讓它嘗試
• babysitting AI 101

To Be Continue

畫個餅，之後有空會再讓AI把這些東西合併成一些 skills 來用，成功的話明天一起更新

明天我們會來看看如何從各種神奇地方取得 Firmware，以及如何選擇研究目標。

參考資源

[1] https://medium.com/@tunacici7/bootloaders-the-wilderness-of-the-firmware-5a9b13c1bffd
[2] https://buildfromzero.com/posts/zephyr-rtos-taking-your-embedded-projects-to-the-next-level/
[3] https://dillan.org/articles/how-to-get-root-access-to-your-sleep-number-bed